home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / C++ AppleLink Messages / CPlus.Dev$ 4⁄13⁄90 / 0102-USENIX C++ Conferenc-Apr90 < prev    next >
Encoding:
Text File  |  1990-04-16  |  12.6 KB  |  285 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  STONECUTTER  to HAUSER
  2.  
  3. Item    1698290                         12-April-90        00:42PDT
  4.  
  5. From:   AUSTAUX                         Australia - A/UX Suppt, K Sandvik
  6.  
  7. To:     CPLUS.DEV$                      C++ Interest List--Developers
  8.         CPLUS.APPLE$                    C++ Interest List--Apple Employees
  9.  
  10. Sub:    USENIX C++ Conference Report
  11.  
  12. Hello all,
  13.  
  14. this is an informal conference report about the San Francisco USENIX C++
  15. conference that was held this week. Disclaimer: the personal comments are mine
  16. and represent my opinions only (not Apple's). Also please forget me concerning
  17. any typos, grammar errors and technical glitches/blunders....
  18.  
  19. Anyway,
  20.  
  21. EXECUTIVE SUMMARY:
  22.  
  23. This year's USENIX C++ conference in San Francisco did not have any big
  24. surprises. The highlights were a new changed scheme of exeption handling that
  25. Bjarne Stroustrup presented, a new religious war between class library builders
  26. concerning small classes against big class trees, presentations with big
  27. scientific applications that made use of C++, and AT&T showed an interesting
  28. papers about how to dynamically link objects into runtime code. There were also
  29. many other papers presented about object oriented network solutions.
  30.  
  31.  
  32.  
  33. TO BUILD OR NOT TO BUILD A TREE - THAT IS THE QUESTION
  34.  
  35. James M. Coggins from University of North Carolina had a paper about building
  36. class libraries. He triggered a small war between class library builders with
  37. comments such as "Big monolithic hierarchies impose considerable overhead" and
  38. "You should not have to pay for what you don't use". He was aiming at class
  39. libraries that were structured as a big inheritance tree, style SmallTalk.
  40. Programmers, such as Keith Gorlan (the man behind the NIH library) did not like
  41. this at all...
  42.  
  43. I think this is actually a good time to start thinking about if C++ libraries
  44. really need to be founded on the SmallTalk class hierarchy model. Maybe it is
  45. suitable in many cases to build small class libraries that does one thing well.
  46. And by using single/multiple inheritance the application developer could put
  47. together the final mix of classes.
  48.  
  49. Another issue that Coggins talked about was the problem of Object Oriented
  50. Design that encourages bottom-up design. This usually leads to a lack of an
  51. architectural vision of the end result. This is especially true of designs
  52. where small libraries are combined to big ones.
  53.  
  54. Coggins wanted to see more 'practical' class libraries that could be used to
  55. create applications, I assume that he wants more specialized class libraries,
  56. e.g. for scientific computing. He commented: "Build classes for sets of
  57. applications".
  58.  
  59. For the moment those few class libraries that exists for C++ seems to be very
  60. monolithic an huge. Maybe it is time to start working with more tools oriented
  61. special class libraries.
  62.  
  63. AT&T ANNOUNCES STANDARD C++ CLASS LIBRARIES
  64.  
  65. Speaking of class libraries, AT&T announced that it will finally distribute
  66. those 'famous' C++ class libraries that they have used internally within the
  67. company. These libraries contain:
  68.  
  69. • Bits - a Bits object that represents bit strings for bit manipulation.
  70. • Block - a sequence of zero or more elements, each of which is of type block.
  71. • Duration - a time difference class, durations can be measured and calculated.
  72. • Fsm - a deterministic finite state machine class that consists of a set of
  73.   transitions between states. A transition from a given state is triggered
  74.   by an integer input and causes a programmer-defined action routine to be
  75.   called.
  76. • ipcstream - UNIX InterProcess Communication class
  77. • List - a linked list of zero or more elements
  78. • Map - a collection of elements, each contains a a key part and a
  79.   value part (associated arrays? -Kent-).
  80. • Objection - a class for implementing simple error handling in C++.
  81. • Place, time zone information class.
  82. • Pool, a colletion of elements, each one is a chunk of *unspecified* type
  83.   of contiguous memory.
  84. • Stopwatch - a timer class, the name tells everything.
  85. • String - string class.
  86. • Strstream - provides the iostream and streambuf classes specified for
  87. Strings.
  88. • Time - calendar date and time-of-day information
  89.  
  90. Well, most of these classes are not hard at all to implement. The nice thing is
  91. to have a set of AT&T defined classes. This means that people could start
  92. writing standard class library code, and know it will be portable across
  93. platforms. Most of these classes are easy to port to the Mac platform anyway,
  94. in the case of time classes one only needs to change the time generation
  95. information.
  96.  
  97. AT&T RELEASES INFORMATION ABOUT 2.1
  98.  
  99. The next release of C++ - C++ 2.1 - is mostly a software maintenance release.
  100. The reference manual is also updated. Actually the this reference manual is
  101. accepted as the base document for X3J16 (the ANSI effort to standardize C++).
  102. C++ 2.1 also introduces new scoping rules and syntax for nested types. It also
  103. has an improved optimization of virtual tables.
  104.  
  105. Those who waited for parameterized types and exeption handling, wait. C++ 2.1
  106. should be available now from AT&T.
  107.  
  108.  
  109. C++ AND WINDOW SYSTEMS
  110.  
  111. AT&T has also announced that it will provide C++ classes for building Open Look
  112. applications. The class API has actually also possibilities to compile Motif
  113. "Look and Feel" interfaces. It could happen that the programmer could select
  114. easily what 'flavor' of interface they want. If this is the case it would mean
  115. a small breakthrough in this current holy windows war.
  116.  
  117. According to the grapewine the next release of X Windows (X11R5) will have as
  118. one of the new features class libraries, so there's a lot of activity going on
  119. concerning object oriented extensions to window interfaces. All this leads
  120. to...
  121.  
  122. GLOCKENSPIEL AND MACINTOSH PROGRAMMING
  123.  
  124. I spoke with Fergal Dearle from Glockenspiel who is one of the architects
  125. behind CommonView, a  grand attempt to provide a window class library that will
  126. provide support for Windows, Presentation Manager, X Windows and Macintosh
  127. windows programming. A kind of Grand United Theory for Windows on personal
  128. computers...
  129.  
  130. He said that the Macintosh library part should be shipped late this year (add a
  131. couple of months to that). They will provide libraries that will work with
  132. either MPW C++ or with the Glockenspiel C++. They actually intend to port their
  133. C++ for MacOS. Ultimately this would mean that they also will port their
  134. existing/new C++ development tools for MacOS as well.
  135.  
  136. Personally I don't think these common window class libraries are good - it
  137. leads to design cludges where the designer has to make so many compromises so
  138. the end result tastes like nine-month-old beer.
  139.  
  140. Then again there are many corporate inhouse software departments who would love
  141. to use something like CommonView in order to solve their future problems with
  142. providing solutions to a scattered set of personal computer brands within the
  143. company.
  144.  
  145.  
  146. EXCEPTION HANDLING WITH C++
  147.  
  148. The concept of exeption handling was one of the hot buzzwords at the
  149. conference. There is already a paper written by Bjarne Stroustrup and Andrew
  150. Koenig from AT&T, but they had to revise some parts of the specification
  151. because the ANSI C++ committee did not like the suggested key names. Well,
  152. if the committee will from now define what is right and what is wrong, expect
  153. the stagnation of C++...
  154.  
  155. The reason why C++ needs exeption handling is how to handle error problem
  156. between a separately written class library and the application that makes use
  157. of the class. The class library is able to detect errors, but does not know how
  158. to signal this back to the application. The application is able to recover from
  159. errors, but can't detect them. By providing a syntactically defined exception
  160. handling in the language itself is a way to officially define a channel for
  161. sending exception information.
  162.  
  163. The basic form is this:
  164.  
  165. int f()
  166. {
  167.     try {
  168.         return g();
  169.     }
  170.     catch (xxii) {
  171.     // if 'xxii' exeption occurs, we get here
  172.         error("g() goofed: xxii");
  173.         return 22;
  174.     }
  175. }
  176.  
  177. int g()
  178. {
  179.     return h();
  180. }
  181.  
  182. int h()
  183. {
  184.     throw xxii();       // here make the exeption xxii to occur
  185. }
  186.  
  187. Function f() tries function g(), if g() barfs it will send an exeption
  188. that catch tries to catch. The programmer is able to define those exceptions
  189. that it want to catch. And the exeption is triggered by the throw statement.
  190.  
  191. The best thing to figure out who throw works is to compare it with a normal
  192. 'return' statement.
  193.  
  194.  
  195. NETWORK SOLUTION AND C++
  196.  
  197. Personally I am interested in the possibilities of classes combined with
  198. networks. With that I mean solutions with virtual object store databases, and
  199. applications that access classes from the database and use them in runtime.
  200. This would mean big opportunities to write applications that modify themselves
  201. in runtime, for instance accesses classes/objects that it normally does not
  202. need. The classes could be 'rented' from a software house and the bill arrives
  203. one month later. This is also a great way to rapidly distribute object
  204. viruses... Beware of dynamically loaded Public Domain objects.
  205.  
  206. Anyway Ravi Sethi from AT&T Laboratories presented a paper aobut adding new
  207. code (objects) to a running program. He called this method dynamic linking.
  208.  
  209. The whole trick is to define a base class and a derived class. The function
  210. names that are declared virtual in the base class are type-checked statically,
  211. but they are bound *dynamically*.
  212. If we add a map that provides from the base class access to classes
  213. yet-to-be-derived from base class, and this map is updated when a new class
  214. is linked into the running program, then we could dynamically add code
  215. resources (sounds complicated compared with the Segment Loader in the Mac,
  216. -Kent-).
  217.  
  218. Thus we have a fake "string" in the basic map, and when the class reads in
  219. the new derived class from a file for instance, it updates the string in the
  220. map and triggers this new class instead.
  221.  
  222. Another interesting paper was about 'Fragmented Objects'. The representation of
  223. this object is distributed amongst processes over a network. The base for this
  224. is an operating system experiment called SOS. In this model the object could be
  225. running in various different memory locations at the same time. Hair raising...
  226. A so called FOG (Fragment Object Generator) was able to create these beasts.
  227.  
  228. Finally Choices, the object oriented experiment operating system,  was
  229. presented. Choices is an extremely interesting case study in how to write both
  230. a portable and an object oriented operating system. It is actually ported to
  231. the Mac II range (I think Bill Joy is still hiding somewhere in Palo Alto,
  232. working on similar directions with a future System V UNIX).
  233.  
  234. The networking base class object in Choices is a so called "Conduit",
  235. a pipe-like class with input and output methods. It actually reminded a lot
  236. of a UNIX streams concept embedded in a class definition. Well...
  237.  
  238. FAMOUS LAST WORDS
  239.  
  240. Well, this conference did not have any spectacular announcements. We are
  241. still waiting for some final official releases of both parameterized classes
  242. and the exeption handling model.
  243.  
  244. As it looks today there is no big leaps happening in the C++ language itself.
  245. It looks like AT&T and other big companies that have invested a lot in the
  246. language wants that the language is stable for the time being.
  247.  
  248. We are still missing things like run-time access to type information in classes
  249. (the class:ical problem of what class type is this beast), more of practical
  250. browser, visualizer and debugger tools for C++, hooks to store objects in
  251. virtual object stores (something that Eiffel and a famous OODB company in
  252. Oregon are rumored to test just now), maybe some initial efforts to provide
  253. a standard run-time garbage collector (yes I know it is luxury...), and
  254. what about concurrency control for future thread-oriented tasks?
  255.  
  256. Gulp, I started to sound like some of the presentators, that happily
  257. created new buzzwords on the flight, such as "proxy object call",
  258. "fragmented objects", "fine-grain object models", "remotable class,
  259. combination of remote and invocable!", "continuation models". As
  260. English is not really my native language I once had to hurry out during one of
  261. the breaks to the nearest book shop, and I had to consult the Websters
  262. dictionary in order to understand the contents of the latest session...
  263.  
  264. Jim Waldo from Apollo actually suggested a price for the paper with biggest use
  265. of buzzwords.
  266.  
  267. COMMENT OF THE CONFERENCE:
  268.  
  269. "Read my LISP, no new syntax"
  270.         -- Michael Tiemann about the GNU C++ implementation of the
  271.            exeption handling, that actually was based on the old Stroustrup
  272.            syntax scheme. Oops.
  273.  
  274. Anyway I have to stop now, if anyone is still reading this line I really
  275. appreciate that you read the whole article. I highly recommend to get the
  276. USENIX C++ 1990 Conference proceedings from USENIX ($28).
  277.  
  278. Live long and prosperous,
  279.  
  280. Kent Sandvik
  281. Apple Australia DTS
  282.  
  283.  
  284.  
  285.